Turnbull China Bikeride/Turnbull China Bikeride - Disc 1.iso/HENSA/MATHS/PLPLOT/PLPLOT.ZIP/doc/notes4.99d

Text File | 1993-10-25 | 11.9 KB | 259 lines

Pre-announcement
----------------

As I mentioned in the previous plplot beta update, I have been working on a
plplot TCL/TK driver under Unix/X (if you're not running Unix/X you might as
well skip this message).  Well, I am now far enough along that I can
confidently say it will see the light of day before too long, on the order of
weeks I hope.  It should be really nice, too, and am letting everybody know
ahead of time so that you can go get the TCL/TK distribution (if you don't
have it already) and start playing with it.  TCL is an embeddable interpreter
in the spirit of Perl, and TK a Motif-like toolkit.  They are free and very
high quality; furthermore, constructing the script language & interpreter
together with a toolkit appears to be an outrageously useful thing to do.
You have to try it to see why.  For more info, consult the substantial
documentation (and demos) for TCL/TK.  I have appended the FAQ to the end of
this message.  To quickly find the section on how to get TCL/TK and assorted
other stuff, search on the string "Tcl/Tk Package Catalog".

Moving on, the basic code is done and I am finally getting simple plots out.
What I have is the following:

User-code
       |
   plplot tk driver                         plserver
   TCL interpreter <------ tk send ------> interpreter
           |                                    |
       data writer  ---- named pipe -----> data reader
                                                 |
                                           child X window

The user-code and the renderer (tentatively called plserver, I may change
this) form a client/server relationship, and are separate processes.  Under
typical usage, where the user-code starts first, it forks (vfork on systems
that support it) and execs the renderer.  TCL/TK communication (via X
properties) is used between their embedded interpreters to send commands back
and forth (note: an extended version of TCL called TCL-DP allows sockets
to be used for this, and I will eventually try to extend the model to
allow distribution across a network).  The existence of an interpreter in
each process (actually each plplot stream that uses tk too) allows for
a very easy & robust method of sending commands between processes.
The data goes through via an alternate channel (fifo for now, maybe socket
later) for maximum speed.

Also I will support an alternate configuration where the server launches
applications, telling them what plplot widget to plot to.  Lots of nice
possibilities there.

By offloading the GUI-building code into a simple script language, it becomes
easy to build menus, buttons, scrollbars, etc.  All of these will be
configurable by the user, as well as the ability to map events (such as
button presses) to functions calls in your own program.  But you will need to
learn TCL/TK to get maximum benefit.  Even without additional effort,
however, you will be able to use the new driver's menus to do zooming, dump
to file, etc.

More later..

--
Maurice LeBrun    [e-mail]
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

From [e-mail] Thu Aug 19 11:24 CDT 1993
Received: by dino.ph.utexas.edu
    (1.37.109.4/16.2) id AA13028; Thu, 19 Aug 93 11:24:46 -0500
From: Maurice J. LeBrun <[e-mail]>
Return-Path: <[e-mail]>
Subject: slowness of the TK driver over the net
To: [e-mail]
Date: Thu, 19 Aug 93 11:24:46 CDT
Cc: [e-mail], [e-mail],
        [e-mail]
In-Reply-To: <[e-mail]>; from "William D. Nystrom" at Aug 19, 93 9:28 am
Mailer: Elm [revision: 70.85]
Status: RO

>      Also, I used plrender to render a meta file on dino and display on
> ctrss2.  One thing that I noticed is that it seems to take much longer for
> the plots to be displayed running the tk driver than just the standard X
> driver.  Do you notice that locally on dino?  Also, do you have a good demo
> meta file lying around that I could grab and try?  I could not get plrender
> to go backwards with my meta file using the tk driver and wonder if it is
> because the meta file was generated by an ancient version of plplot.
>
>         Dave

The current incarnation of the TK driver is going to run a bit slow
over a network because of the way messages are passed between the
user code and the renderer.  In this case plrender is the user code
and it forks the actual renderer.

The TK send command does IPC by storing messages in an X property
of the display.  This means that when running over a network, messages
must travel from the X client to the X server and then back again.
Kind of sick, I know.  So for the time being I recommend using the TK
driver primarily locally.

Eventually I will switch to a scheme where the renderer runs on the
display server.  I don't think there will be many changes required for
this to work.  The FIFO becomes a socket, and the TK send is replaced by
Tcl-DP's send (which uses sockets).  I have to work out how to start the
remote renderer.  Probably it could try doing a remsh (or rsh on systems
that don't have remsh), and if it fails for security or other reasons,
tell the user to start the renderer manually using some specified socket
for communication.  I don't feel like getting into all this now but that's
sort of how it will look.

--
Maurice LeBrun    [e-mail]
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

From [e-mail] Tue Sep  7 23:55 CDT 1993
Received: by dino.ph.utexas.edu
    (1.37.109.4/16.2) id AA29917; Tue, 7 Sep 93 23:55:50 -0500
Date: Tue, 7 Sep 93 23:55:50 -0500
From: Maurice J. LeBrun <[e-mail]>
Return-Path: <[e-mail]>
To: [e-mail], [e-mail],
        [e-mail], [e-mail]
Subject: CVS update notice
Status: RO

Update of /u/tpc/cvs/plplot/sys/unix
In directory dino:/u/mjl/devel/plplot4p99d/sys/unix

Modified Files:
    makefile.m4
Log Message:
Now passes in INSTALL_DIR as a string containing the installation
directory, typically /usr/local/plplot.  Files that get this information
include plfont.c (for use in the font search path), plserver.c (for use in
the autoload search path), and tk.c (to search for plserver befor the
fork/exec).  The environmental ${PLPLOT_DIR} is ALWAYS placed before
INSTALL_DIR in the search path in each case, so there is ready escape
from the tyranny of a hardwired location.


From [e-mail] Fri Jul 16 23:54 CDT 1993
Received: by dino.ph.utexas.edu
    (1.37.109.4/16.2) id AA06269; Fri, 16 Jul 93 23:54:30 -0500
From: Maurice J. LeBrun <[e-mail]>
Return-Path: <[e-mail]>
Subject: plplot libraries
To: [e-mail], [e-mail],
        [e-mail]
Date: Fri, 16 Jul 93 23:54:30 CDT
Cc: [e-mail]
Mailer: Elm [revision: 70.85]
Status: RO


I finally got around to making a test that I was curious about.
I compiled plplot's x01c under a variety of configurations to see the
effect on executable size (on disk, stripped).  This is all under
HP/UX.

Xlib (shared)   Xlib (archive)  TK (archive)    size
-----------------------------------------------------
no        no        no        233 KB
yes        no        no        246 KB
no        yes        no        406 KB
yes        no        yes        754 KB
no        yes        yes        918 KB <- getting up there,
                     but still smaller than with Motif :-)

As can be seen, the penalty was almost zero when the shared X library was
used, and probably the same would occur if the TK library were made
shareable.  Although this doesn't mean there is no penalty for hooking up
with these libraries, it does amount to a big savings in disk space
(obviously), and I think even of run-time image if more than one app
using these libraries is running (since only one copy needs to be in
memory at a time).

Unfortunately it's still far from clear what libraries to retain in general.
For workstations, I'd say *usually* go with the full Xlib & TK version,
although it may be useful to provide libraries that have no X dependence.
For Crays it becomes more difficult.  Partly because UNICOS has no shared
libraries, and the libraries are bigger to boot.  But also it isn't clear
that the TK driver will even run with acceptable speed, never mind whether
running a GUI is appropriate use for a Cray (eventually the TK driver will
become distributed and this point will become moot).  So on the Cray, it's
tempting to provide libraries for use with the Xlib driver only, except that
plrender be built with the TK driver as well.  Probably I won't decide this
until I actually get TCL/TK up on the Crays and get to play with the TK
driver out there.

If one were to allow for the possibility of building all three libraries
it might look like the following:

libplplotf.a        no Xlib or TK
libplplotfX.a        Xlib only
libplplotftk.a        Xlib and TK

This would be nice from the user perspective if all sites followed this
convention.  You would have no problems getting the right one from your
makefile regardless of the system.  Or you could make a soft-link from
whichever one of these you really want to ~/lib/libplplotf.a if you really
want to simplify things.

But including the double precision versions you get 6 libraries.  Double it
again for shared library versions.  Yes, that's 12 -- and getting ridiculous.
Time to backtrack.

The system administrator is ultimately the arbiter of what goes on.  He
supposedly knows what libraries are the best match for his system and
user base, and is also ultimately responsible when things go wrong.

So, I think the best compromise both gives some consistency to the user
across multiple platforms while letting the sysadm tailor the choice of
libraries.  As I envision it there will always exist at least two libraries
-- libplplotf.a and libplplotd.a (actually one of these may be a softlink to
the other, such as on Crays where float==double).  These are then linked to
the libraries that are the best default for the system.

This is then:

(a) consistent -- the user can use libplplotf.a everywhere he goes with
reasonable results.  The one minor pain here is that the linkage may be
different from site to site, (-lX11 for the X driver, and -ltk -ltcl for the
TK driver).  So probably a file called libplplotf.doc should exist with
libplplotf.a that explains the linkage.

(b) flexible -- the system administrator can add as many custom libraries
as desired.  The users can either link against them explicitly or put
a soft-link from the desired library to ~/lib/libplplotf.a.  And you can
change the system default (say, if you change your mind or many people
request it) simply by changing a soft-link (and possibly building a new
library version).

The makefile will make the system administrator's job easier by adopting the
naming scheme mentioned above (something like libplplotfn.a for the library
without Xlib or TK, if I bother to support it).  The exact name doesn't
matter much since you'll be relying on softlinks to set the system defaults,
but it's good to be consistent.

Probably for now I'll just add the two new libraries libplplotftk.a and
libplplotdtk.a on workstations as I had previously planned.  The system
default libplplotf.a could be made to point to these eventually (on dino,
soonest, although I still have to check out the TK driver on Mark's
X-terminal).  On the Cray, I'll leave the system default as-is until I can
check out the TK driver on it.

Does this scheme sound reasonable to everyone?
--
Maurice LeBrun    [e-mail]
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]